IBIS Macromodel Task Group Meeting date: 15 July 2014 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: * David Banas ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis Ericsson: Anders Ekholm Intel: Michael Mirmak Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow * Bob Ross The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: ------------- New Discussion: Draft BIRD for matrix value: - Randy showed a draft BIRD. - Randy: This came from a model with a negative resistance that IBISCHK did not catch. - Adding a requirement to the specification would drive a new IBISCHK check for that. - Three statements are added. - Should it be "positive" or "non-negative"? - Radek: "non-negative" is good. - Mike: Is zero allowed? - Arpad: Yes. - Randy: Vladimir at Mentor gave some feedback. - He suggested other checks that might be done. - Diagonal dominance for C. - Radek: There are checks like passivity that are beyond what we should do. - Bob: The intent is to do only simple checks. - Arpad: Checking for positive off diagonals is not a hard test. - Where do we draw the line? - Walter: We might want a best practices white paper. - Bob: An analysis might blow up with bad data. - Arpad: Do we have to check all of these rules? - Bob: Maybe not. - Radek: Maybe EDA tools should do this. - Mike: It is fair to have rules that are always true, should never be violated. - Is the phrase "will be" correct for this? - Radek: It should be "shall be". Back-channel: - Arpad showed a single slide. - Arpad: We have reached no consensus. - Complete optimization should not be part of IBIS. - Any vendor can handle that without IBIS changes. - Both proposals rely on the RX to control optimization. - SiSoft would support legacy TX models. - BIRD 147 could be extended to allow the EDA tool to act on behalf of the TX. - Ambrish: It is not true that we look at only tap settings. - The EDA tool can't help legacy models in that case. - Arpad: Could you list some parameters? - Ambrish: Jitter compensation, for example. - Ken: We should not expand the scope of BIRD 147. - We should finish the BIRD by the end of the month. - Radek: The dependence on BIRD 128 must be discussed here. - BIRD 147 is not sufficient and potentially dangerous. - There are memory allocation issues. - We should extend the API. - There should be no issue if we excluded legacy models. - Ken: I'm not familiar with BIRD 128 - Arpad: AMI_GetWave does not allow InOut parameters. - Ken: I think BIRD 147 has something about that, does it reference BIRD 128? - Ambrish: Yes. - Radek: Memory allocation protocol must be specified. - Arpad: I would like GetWave to have a consistent footprint. - Radek: It could be AMI_GetWave or BCI_GetWave. - New DLLs will be needed, there should be no problem. - Ambrish: The current approach has been tried and it works. - Radek: We don't want to find out years from now that something is wrong. - Arpad: We should discuss BIRD 128. - Radek: We could describe a new API in BIRD 147. - Ambrish: What we have is sufficient, adding more might be redundant. - Arpad: A future feature that needs InOut would have to use BCI_GetWave but that's awkward. - Ambrish: GetWave can do it. - Ambrish: With overloading we can have the same function with different arguments. - Radek: The name is OK, but this is an extended API. - Arpad: Should BIRD 128 language be folded into BIRD 147? - Radek: Yes. - Ambrish: Is the rest of BIRD 147 settled? - Arpad: We can add BIRD 128 content to BIRD 147 and vote down BIRD 128. - Radek: I still want to see a proper API without using AMI_parameters_out. - Arpad: Yes, not exactly what BIRD 128 proposes. - Mike: Something in the AMI file has to indicate AMI_GetWave has a different call signature. - Ambrish: It would be good if Radek could help. - Radek: I will try. Agenda list: - Mike: Can we drop item 15? - Arpad: It has been discussed in other circles. - Greg Edlund has not attended these meetings for some time. - Walter: There was an email thread about NAs for min and max data. - It might be best to have another place to address issues like that. - Arpad: The spec seems to say in some places to use typ for NA - It does not say that for V-T and I-V tables though. - Some combinations can make no mathematical sense. - The data that do have mathematical relationships might need some rules. - Walter: In some tables only some values are missing and it's OK to interpolate for those. - The problem is when an entire column is missing. - Mike: IBISCHK can issue Notes, Cautions, and Warnings for things not in the spec. - Arpad: New tables like ISSO have some conditions that are impossible. - Mike: Checks like the V-T to Ramp checks would be OK - But finding one non-NA value in a column should not start a check - Arpad: Some things can be synthesized, but it has limits. - Radek: The rules are for individual pieces of data without discussion of interdependencies - Establishing those would not be backward compatible. - Some checks could provide insight into the missing data. - We have many IBIS files out there. - Bob: This is a day one mistake - we should have required all values in a column to be filled in or none. - We can only make a strong recommendation. - Randy: It's a little scary that someone could simulate with a model that is missing data. - There should be warnings or errors for this. ------------- Next meeting: 22 Jul 2014 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives